-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to grpc-dotnet #517
Move to grpc-dotnet #517
Conversation
# Conflicts: # Client/Client.csproj
…tNetMigration # Conflicts: # Client.IntegrationTests/ZeebeIntegrationTestHelper.cs
resolves #348 |
# Conflicts: # Client.Cloud.Example/Client.Cloud.Example.csproj # Client.Examples/Client.Examples.csproj # Client.IntegrationTests/Client.IntegrationTests.csproj # Client/Client.csproj
Ok, I stop working on this PR until you have a bit of time for review. I cannot fix conflicts everyday, it's not possible. Everybody knows that a PR/branch must not live too long otherwise it becomes unmanageable and this is exactly what happens... A bit upset, I admit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @xlegalles first thanks that you did this and provided a solution for it. Right now I'm have not really time to maintain this project, we try to find someone else to take over that. Furthermore, I was off the last few weeks (dependabot gets merged automatically), so sorry for the late response.
I haven't looked at all details in your PR, but what I have seen is that there are a lot of changes that change code style and move classes/files. This makes it quite hard to review (it is not clear what are the important parts and what not).. Over 1k lines of changes are not optimal to review in general. Would be nice if we could avoid the style changes. If we need them let's either create a separate commit for it or better create a separate PR for it.
Furthermore, please follow the contribution guide, and adjust your commit messages etc.
Ok, I'm going to revert some changes that are mostly related to code style. A lot because now namespaces can be defined without any brace, which is a nice improvement but changes all file content.... |
# Conflicts: # Client.Examples/Client.Examples.csproj # Client.IntegrationTests/Client.IntegrationTests.csproj # Client.UnitTests/Client.UnitTests.csproj
deps(client): uses Grpc.Net instead of Grpc.Core fix: camunda-community-hub#348
deps(client): uses Grpc.Net instead of Grpc.Core fix: camunda-community-hub#348
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test class has been splitted because some tests require a test server while others do not need any.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @xlegalles
sorry that it took me so long. I'm quite busy with other stuff (zeebe etc.)
I have some questions which we should clarify before we continue I think, see below.
I used the emoji code for the review, which we use also @ Zeebe. For more information take a look here https://github.com/camunda/zeebe/blob/main/CONTRIBUTING.md#reviewing-a-pull-request
@@ -18,6 +19,7 @@ public async Task ShouldSendRequestAsExpected() | |||
{ | |||
ProcessInstanceKey = 12113 | |||
}; | |||
TestService.Reset(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ For what these resets have been added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed the logic of these tests and share the same server across all. The execution is now way more faster. But I need to reset its state, otherwise the expectation is polluted by previous methods.
<PackageReference Include="Grpc.Tools" version="2.55.1"> | ||
<PrivateAssets>all</PrivateAssets> | ||
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> | ||
</PackageReference> | ||
<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="7.0.0" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ There have been some dependencies removed. How does this work now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The restoration process is able to manage transitive dependencies so that you don't need to specify them. If you do you will have to manage them, and ensure they are consistent with your primary dependencies.
return new ZeebeClient(Address, Credentials, KeepAlive, SleepDurationProvider, LoggerFactory, Certificate); | ||
} | ||
|
||
private X509Certificate2 CreateFromPemFile(string fileName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❌ Feels like this shouldn't be part of this PR, is this another feature you want to get merged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok nevermind I have re-read our PR description:
I guess it is this:
The tricky part was about certificates and I've put some comments in ZeebeSecureClientBuilder.
One important remark in ZeebeClient: because the certificates we use for tests are untrusted, I have to add a RemoteCertificateValidationCallback line 86 to bypass validation. I'm not sure if this is relevant? In our case, we often use OpenSSL certificates and we have to use such a validation. But at a consequence the ShouldFailOnWrongCert UT does not work anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is the explanation.
/// The "user-agent" is already filled by grpc-dotnet | ||
/// typically something like: key=user-agent, value=grpc-dotnet/2.53.0 (.NET 7.0.5; CLR 7.0.5; net7.0; windows; x64) | ||
/// </summary> | ||
internal class CustomHeaderInterceptor : Interceptor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Was this extracted? Why the change of the user agent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to maintain the behavior that you have implemented with a specific user-agent description. If I don't do this you will receive on the server, the generic description of a .net grpc agent.
Hey @xlegalles thank you for your time and effort! I had a deeper look at this issue and it seemed to me that most of the changes were not really necessary. I made separate PRs to migrate to .net 7 #543 and to migrate to grpc-dotnet #545, both involved not much (or none) refactoring. I will implement/add some more features which have been recently added to Zeebe and then release a v2.0. version. Thanks again and sorry that I was not able to merge your PR. But I hope that you're happy with the end result anyway and it helps you in your project as well. P.S.: Small recommendation, for the next time, please try to create smaller PRs (with fewer changes) it makes it easier to review and reason about. For example, try to split bigger changes up. Plus try to discuss the changes you want to do first in a separate issue, so you not working on changes unnecessarily which might not get accepted or merged. Thank you again 🙇🏼 |
Hi Christopher,
I understand your point of view and will do differently next time. And of
course, I'm satisfied that we can use the new version.
Thank you
Xavier
Le sam. 15 juil. 2023, 09:21, Christopher Kujawa (Zell) <
***@***.***> a écrit :
… Hey @xlegalles <https://github.com/xlegalles> thank you for your time and
effort!
I had a deeper look at this issue and it seemed to me that most of the
changes were not really necessary.
I made separate PRs to migrate to .net 7 #543
<#543>
and to migrate to grpc-dotnet #545
<#545>,
both involved not much (or none) refactoring.
I will implement/add some more features which have been recently added to
Zeebe and then release a v2.0. version.
Thanks again and sorry that I was not able to merge your PR. But I hope
that you're happy with the end result anyway and it helps you in your
project as well.
P.S.:
Small recommendation, for the next time, please try to create smaller PRs
(with fewer changes) it makes it easier to review and reason about. For
example, try to split bigger changes up. Plus try to discuss the changes
you want to do first in a separate issue, so you not working on changes
unnecessarily which might not get accepted or merged.
—
Reply to this email directly, view it on GitHub
<#517 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABYFC7JFWE6WLAVAMOINUDXQJAHNANCNFSM6AAAAAAYFKPCU4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
It targets net5.0;net6.0;net7.0 but I don't know if net5.0 is still relevant (not supported any more).
Also, tests only target net7.0.
I propose to update this package to v2.0 but of course, you decide.
I have tried to remove as many warnings as possible.
All unit tests now use a standard host instead of a Grpc.Core.Server which does not exist anymore. In that context, GatewayTestService cannot be resolved from DI. This is why I have created IRequestHandlerRegistration which encapsulate the logic for tests: it's a singleton component whose state can be reset.
In BaseZeebeTest, I have changed the lifecycle of this host and made it unique for all tests: the execution of tests is of course much faster.
The tricky part was about certificates and I've put some comments in ZeebeSecureClientBuilder.
One important remark in ZeebeClient: because the certificates we use for tests are untrusted, I have to add a RemoteCertificateValidationCallback line 86 to bypass validation. I'm not sure if this is relevant? In our case, we often use OpenSSL certificates and we have to use such a validation. But at a consequence the ShouldFailOnWrongCert UT does not work anymore.
I'm available for any discussion/comments but maybe not before 21th as we have public holidays in France.